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METHOD FOR SUPPORTING THE NAME DELIVERY FEATURE FOR 
MIXED TDM NETWORKS/ SIP CENTREX COMMUNICATION 

ARCHITECTURES 

CROSS REFERENCE TO RELATED APPLICATIONS 
[0001] This application is the US National Stage of International Application No. 
PCT/EP2004/051957, filed August 30, 2004 and claims the benefit thereof. The 
International Application claims the benefits of German application No. 10341087.2 DE 
filed September 5, 2003, both of the applications are incorporated by reference herein in 
their entirety. 

FIELD OF INVENTION 

[0002] The present invention relates to a method for supporting the name delivery 
feature for mixed TDM networks/SIP CENTREX communication architectures. 

BACKGROUND OF INVENTION 

[0003] More recent communication architectures provide for the separation of call- 
processing networks in communication service related units and the transport of the 
payload (Bearer Control). This results in a decomposition/ separation of call set-up and 
medium or bearer set-up. The payload can be transmitted (through-connection of the 
traffic channel) via different high bit rate transport technologies such as, for example, 
ATM, IP, Frame Relay. With a separation of this type, the telecommunication services 
currently used in narrow band networks can also be realized in broadband networks. 
Thereby the subscribers are connected either directly (e.g. via a DSS1 protocol) or via 
exchanges designed as Media Gateway Controllers (MGC) (e.g. via the ISUP protocol). 
The payload itself is converted by the Media Gateways (MG) used in the respective 
transport technology. The Media Gateways are controlled by respectively allocated 
Media Gateway Controllers (MGC). The Media Gateway Controllers use the standard 
protocols, such as, for example, the MGCP protocol or the H.248 protocol to control the 
Media Gateways. In order to communicate between each other, the Media Gateway 
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Controllers use an ITU standardized BICC (Bearer Independent Call Control) protocol, 
which is a further development of an ISUP protocol. The BICC protocol is formed from 
several standardized protocols and thus comprises a protocol family. 

[0004] At the IETF committee on standardization, protocols suitable for the BICC 
protocol emerged with the SIP and SIP-T protocols. The SIP-T protocol (RFC 3204) 
represents an addition to the SIP protocol (RFC 3261). Using the SIP-T protocol, it is 
possible to transmit ISUP messages - in contrast to with SIP protocol. In general ISUP 
messages are transmitted by means of tunnels, i.e. by transparent split-lot transfer. 
Preferably the ISUP-messages issued by a PSTN subscriber are held and supplied to the 
receiving PSTN subscriber together with a bearer message (INFO Method, RFC 2976). A 
general network configuration with TDM -/ IP networks of this type is shown in Fig. 1 . 
Here, by way of example, 2 PSTN networks are shown and in each respective network 
there are several PSTN subscribers arranged in the usual manner. These are connected to 
the local exchanges, LE, which are, in turn, connected to the transit exchanges, TX. In the 
transit exchanges, TX, the separation is now made between signaling information and 
payload. The transit exchange TX supplies the signaling information directly via an ISUP 
protocol to a respectively allocated Media Gateway Controller MGC (the A or B side). 
The payload is transmitted to a Media Gateway MG (arranged at the input side) (the A or 
B side), that functions as an interface between TDM network and an ATM or IP 
transmission network, where it is transmitted in packet mode via the respective 
transmission network (ATM or IP). The Media Gateway MG of the A side is controlled 
by the respectively allocated Media Gateway Controller MGC of the A side as is the 
Media Gateway MG of the B side by the Media Gateway Controller MGC of the B side 
allocated to. In the event that the payload is transmitted from Media Gateway MG of the 
A side to the Media Gateway MG of the B side, then again under the control of the Media 
Gateway Controllers MGC of the B side allocated to the Media Gateway MG of the B 
side, said payload is converted into a TDM data stream and supplied to the PSTN 
subscriber in question. The data transmitted between the Media Gateway Controller 
MGC and the respectively allocated Media Gateway is supported by a standardized 
protocol. This can be, for example, the MGCP or the H.248 protocol. A BICC protocol 
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(or possibly ISUP+ protocol), a SIP or SIP-T protocol can be used as standardized 
protocols between the two Media Gateway Controllers MGCs. Further devices such as 
proxy devices (SIP world) and/ or CMN exchanges (Call Mediation Node, ISUP/ BICC 
world) can be switched between the two Media Gateway Controllers. In principle, it is 
desirable that the features known from the TDM world can also be used in the IP world. 
The Name Delivery feature, known to traditional (TDM) CENTREX subscribers, is 
presented as an example of this. Hereby, under a CENTREX (Central Office Exchange) 
configuration, is to be understood a configuration that includes the realization of features 
of a private branch exchange in subscriber exchanges in the public network. If the lines of 
a user group are connected with each other via CENTREX exchanges and the public 
telephone network, one refers to this as a Wide Area CENTREX. Potential CENTREX 
services users are, therefore: 

- groups with frequent change of location. 

- large interconnected complexes such as high-rises, technology and media centers, 
airports, 

- groups with decentralized structures which generate heavy internal traffic between the 
different locations. 

[0005] In addition Fig. 1 shows the connection of a SIP CENTREX configuration as 
made via a SIP proxy server to a Media Gateway Controller MGC. The information is 
exchanged between the SIP subscribers of a SIP CENTREX configuration using the SIP 
protocol. All the subscriber related data of the CENTREX configuration is managed and 
maintained in the SIP proxy server. 

SUMMARY OF INVENTION 

[0006] In a configuration of this type according to Fig. 1, there is the problem that in 
the mixed operation (Interworking) of TDM networks/ IP networks/ SIP CENTREX 
configurations/ TDM CENTREX configurations, it is not possible to use the Name 
Delivery feature for CENTREX configurations known from the TDM world, as the 
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necessary definitions have not yet been made. 

[0007] An object of the invention is to find a way to enable the Name Delivery feature 
also to be used for networks with mixed TDM configurations/ SIP'CENTREX 
configurations. 

[0008] An object of the invention is achieved by the features specified in the 
independent claim. 

[0009] The advantage of the invention is to be found in the fact that when SIP 
CENTREX configurations are used, any subscriber (SIP or traditional TDM subscriber) 
has the name of the other subscriber (Partner) displayed to him/her. A further advantage 
of the invention is to be seen in the fact that the Name Delivery feature can also be used 
without limitation in ISUP/ BICC/ H323 networks while interworking with SIP network. 
Thereby, the Name Delivery feature includes the sub-feature "Calling Name" (name of 
the subscriber calling is displayed) and also "Connected Name" (name of the subscriber 
called is displayed when call taken). 

[0010] Advantageous developments of the invention are specified in the dependent 
claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] The invention is explained in greater detail below with reference to an 
exemplary embodiment illustrated in a figurative manner, in which; 

Figure 1 shows the relationships between 2 PSTN networks between which an 

Internet network is arranged, and with a SIP CENTREX configuration, 

Figure 2 shows the connection of a SIP CENTREX configuration to an Internet 
network with the information elements necessary to realize the Name 
Delivery feature 
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DETAILED DESCRIPTION OF INVENTION 

[0012] According to Figure 2, the invention is explained in more detail with reference 
to an exemplary embodiment. It is hereby assumed that the subscriber of a TDM network 
(A side) calls the SIP subscriber (B side) of a SIP CENTREX configuration - in this case 
the subscriber SIP B. In this case, the signaling connection is routed via a SIP proxy 
(application server) server that supports the Name Delivery feature. 

[0013] To realize this, first it is necessary to decide on the definitions according to 
TABLE 1 for the mapping for the transition ISUP/ BICC to SIP and vice versa. The 
mapping is controlled in the Media Gateway Controller MGC of the B side (although the 
controller functionality is not shown here as there is no Media Gateway present, the 
device MGC of the B side is marked as Media Gateway Controller). As, according to 
prior art (ISUP/ BICC), the Name Delivery feature for TDM CENTREX configuration is 
controlled via proprietary solutions, the name information is held in different protocol 
elements of the ISUP/ BICC protocol. By way of example, two providers AI, A2 are 
displayed. In the case of Al, the name information is held in the ISUP/ BICC protocol 
element "CallingName", in the case of a provider A2 in the ISUP/BICC protocol element 
!, CTX coding/ decoding" (APP parameter (application transport parameter) based on 
ITU-T Recommendation Q.765). In the latter case, the name information is also held for 
the sub-feature "Connected Name". 



Provider 


ISUP/ BICC 


SIP 


Al 


CallingName 


Display field in FROM header/ 
privacy header 


A2:CTX ASE calling 
name 


CTX coding/decoding 


Display field in FROM header/ 
privacy header 


A 2: CTX ASE connected 
name 


CTX coding/decoding 


Display name of the CONTACT 
Header/ privacy header 



2003P13487WOUS Clean Substitute Specification JDH.rtf 
5 of 7 



Attorney Docket No. 2003P13487WOUS 



TABLE 1 

[0014] According to the invention (TABLE 1 , right-hand column) provision is made 
in a first step for the name information for the sub-feature "Calling Name", to be 
transmitted (mapping), in principle, into the protocol element of the SIP protocol 
"Display field in FROM header/ privacy header". In the case of the sub-feature 
"Connected Name", the name information should be held in the SIP protocol element 
"Display name of the CONTACT Header/ privacy header". 

[0015] In a second step, the subsequent actions are displayed in TABLE 2. The name 
information is supplied in the SIP protocol elements "Display field in FROM header/ 
privacy header" to the proxy server SIP proxy via the SIP "INVITE" message. This first 
checks whether the called subscriber SIP B has allowed or applied for the display of the 
name of the calling subscriber (chargeable service). This is possible as the proxy server 
has stored the relevant data for this in a database. This can be an internal database in the 
proxy server itself, but it can also be externally connected to the proxy server. 
Information can also be stored in the database about whether the calling subscriber wants 
his/her name to be displayed or not. If the called subscriber SIP B does not allow the 
name of the calling subscriber to be displayed, the proxy server removes the name 
information from the SIP protocol element "Display field in FROM header/ privacy 
header". 

[0016] Otherwise the name display is removed from the database and entered into the 
protocol element "Display field in FROM header/ privacy header". If the name display is 
already there, then no intervention is made. The name information is supplied to the 
called subscriber SIP B in the protocol element "Display field in FROM header/ privacy 
header" and displayed on the terminal device. 
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SIP 


Proxy server (SIP proxy) 
Database query 


SIP 


FROM header/privacy 
header 


Is the Name Delivery feature 
(Calling Name) desired by called 
subscriber? 


Add or remove 
Display field in 
FROM header/privacy 
header 


CONTACT 
Header/privacy header 


Is the Name Delivery feature 
(Connected Name) desired by 
called subscriber? 


Display name of the 
CONTACT 
Header/privacy header 



TABLE 2 



[0017] In the following, it is now assumed that the called subscriber SIP B accepts the 
call. The name information of the called SIP subscriber SIP B is routed via the SIP 
handshake message 200 OK and analyzed in the proxy server. If the name display is 
allowed at the calling subscriber, then said information is entered into the SIP protocol 
element "Display name of the CONTACT Header/ privacy header", or removed if the 
display is to be suppressed. 

[0018] It should be noted that the invention can also be used if there is no ISUP/ BICC 
protocol between the PSTN subscriber (ISDN, analogue subscriber or also mobile 
communications subscriber) and the SIP subscriber. This means that the method is then 
carried out within the exchange. The interworking of NextGenerationNetwork 
subscribers such as VoDSL, H323 etc. to SIP or SIP-T is thus also possible. 

[0019] In the method just described, the method procedures are separated in the Media 
Gateway Controller and the proxy server. This separation is, however, not mandatory, the 
method procedure can also take place in a single device. 
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